The present invention relates generally to rich internet applications. More specifically, the present invention provides a mechanism by which a business rule engine and its associated business rules can be extended to execute on the client-side of a rich internet application.
As depicted in FIG. 1, conventional web-based applications that utilize business rules rely on a simple request-response paradigm facilitated by the hypertext transfer protocol (HTTP). A conventional web-based application in this request-response paradigm operates as follows. Generally, a user 10 provides input to the application by manipulating various elements of a user interface 12 of a web page, for example, by filling in a form or selecting an option from a drop-down box. After specifying various inputs, a user “presses” or “clicks” a user interface element (e.g., a submit button), which in turn, causes the web browser application 14 executing on the client 15 to communicate an HTTP request to a web application server 16 executing on a server 22. When received at the web application server 16, the request is processed by application logic 18. If necessary, facts included in the request (e.g., the user input) are relayed to a business rule engine 20 residing on the server 22 by writing the facts to a working memory of a business rule management system 24. Next, business rules 26 are evaluated and those business rules having a condition satisfied by the facts in working memory are executed by the rule engine 20. Data resulting from the execution of rules are communicated back to the web application server 16. In turn, the web application server 16 generates application content based on the data resulting from the rule engine execution, and communicates the application content back to the web browser application 14 via an HTTP response message.
There are a number of problems and/or limitations with rule-based web-applications based on this simple request-response paradigm. First, the server-side business rule engine 20 can only be invoked by an explicit user interaction with a user interface element displayed by the browser application. For instance, the business rule engine 20 can only be triggered to evaluate business rules stored in the business rule repository 26 if, and when, a user “presses” or “clicks” a particular button or link causing an HTTP request to be communicated from the browser application 14 to the web application server 16. Consequently, other user interactions, such as cursor movements, page scrolling, key strokes and so forth, cannot be identified as events for the purpose of triggering the evaluation of the business rule set stored in the rule repository 26 on the server 22. Furthermore, the look and feel of the user interface of a web-application based on this request-response paradigm is generally perceived as being static. User interface elements cannot be dynamically modified or updated as the user interacts with the web application. Instead, the layout and content of the web application are updated only upon receiving a new web page via the HTTP response message. Consequently, not only is there a delay (due to client-server communications) in manipulating user interface elements, it is not possible to manipulate a single user interface element without updating or reloading the entire web page.
A variety of new programming tools and techniques have given rise to a new programming paradigm for web-based applications. Web-based applications in this new programming paradigm are often referred to as rich internet applications (RIA's) due to their enhanced look and feel, which closely resemble the responsive look and feel of the user interface for desktop applications. Although there are a variety of competing technologies and techniques (each with its own name) for creating RIA's, one group of inter-related web development techniques consistent with this new programming paradigm is referred to as Ajax. The term Ajax refers to the seamless combination of three powerful, complementary technologies, including asynchronous communications, JavaScript and extensible markup language (XML). Each of these technologies plays an important role in enabling the enhanced look and feel of RIA's. Asynchronous communication refers to the ability of the web browser application to request and receive “behind the scenes” small amounts of relevant data from a web application server, without having to reload an entire web page. JavaScript is a scripting language enabling the execution of code embedded in a web page by a web browser application. Finally, XML is used for the ad-hoc manipulation of various elements of the user interface of a web page, without having to reload a completely new web page. Using these three technologies, application developers can enhance the user interface of web-based applications by “pushing” the processing associated with various user interface elements to the client, thereby giving the user interface of the web-based application a very responsive and dynamic look and feel.
A web-based application leveraging these new programming tools and techniques may include application logic that executes at the client. The client-side application logic may detect and analyze events as they occur, and in turn, asynchronously communicate messages to a server-side business rules management system, requesting the invocation of a server-side rule engine upon detecting the occurrence of certain events. Although such a web-based application provides several advantages over that of FIG. 1, there are still several limitations and problems with such an application, particularly involving the server-side business rules management system. First, because the business rules and their execution environment still reside exclusively on the server, the web browser application must still contact the rule engine every time a user interacts with a user interface element configured to invoke the evaluation and/or execution of a rule. This means that the user interface can only be manipulated to respond to user input after waiting until the web browser application has completed its communication with the rule engine. This has the unfortunate effect of making the client/server communication perceptible to the user, for example, in the form of a long delay. Furthermore, with the application logic residing on the client, any number of fine grained user actions (e.g., keystrokes, button selections, cursor movements, and so on) can be detected and used to trigger the evaluation of a business rule. However, each event detected at the client must be communicated in a message to the server. This may cause the browser application to continuously communicate a stream of event messages from the web browser application to the business rule management system on the server, which has the undesired effect of increasing the processing load on the server and further increasing the perceived delay in processing user interface events.